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(54) METHOD AND APPARATUS FOR ASSISTING DEVELOPMENT OF PROGRAM FOR VEHICLE 



(57) The man-hour required, to develop a vehicle 
control program is reduced. A program generator (1 ) au- 
tomatically generates a vehicle C code from control 
specifications Inputted in the form of a data flowchart 
and in the form of a state flow chart. The vehicle C code 
is downloaded in a vehicle ECU (2). The control of a 
controlled system, which is a vehicle model device (3). 
by the vehicle ECU (2) is monitored by the program gen- 
erator (1) and debugging is performed. Since the vehicle 
C code automatically generated frorh control specifica- 
tions is used, the debugging is easy and reliable. Manual 
coding is obviated. Integer information is added to a 
symbol block of a data flowchart, and therefore a vehicle 
C code of integer logic can be automatically generated 
using the integer information. 



Fig. 1 




Printed by Jouve, 75001 PARIS (FR) 



1 EP1 111 483A1 2 



Description 

TECHNICAL FIELD 

[0001] The present invention relates to a method and 5 
apparatus for assisting development of a vehicle-use 
program, and in particular to an apparatus and method 
which improves development efficiency and reliability of 
a developed program. 

10 

BACKGROUND ART 

[0002] Tools for integrated environment utilizing visu- 
al programming technique have been developed for fa- 
cilitating control system design. Computer software for is 
simulation and programming functions is now common- 
ly used to develop vehicle control systems. 
[0003] When a computer operator working on system 
development inputs specification data into his computer, 
using a simulation function, a specification incorporating 20 
the concepts input by the user is shown on a computer 
display in the form of a data or state flowchart. Simula- 
tions are then executed according to the charts pre- 
pared, and the logic is debugged with reference to the 
simulation, result. V-H'.S' 25 
[0004] Such simulation software has a function of au- 
tomatic generation of a program code, such as C lan- 
guage code, based on a chart prepared. C language 
code prepared in this manner is, however, generally 
lengthy with many steps and thus not suitable for use 30 
intact in vehicle control, which requires severe restric- 
tions on memory and an execution speed. Moreover, 
such C code is very unfriendly because computer-de- 
termined variable names are attached to parts in the 
charts. 35 
[0005] The situation being such, many users choose 
to manually generate vehicle-use Ccodesuitableforve- 
hicle electric control units (vehicle ECU) while referring 
to the data arid state flowcharts: In particular, dedicated 
codes having integer logic are generated. These codes 40 
differ from general C codes and enable high speed 
processing using a smaller memory in view of data bit 
number. This manually generated vehicle-use C code is 
downloaded to a vehicle-mounted ECU, and debugged. 
[0006] Conventionally, as described above, the spec- 45 
ification simulation process and the program coding 
process are separate, and each requires a debug oper- 
ation. Therefore, should a problem be found when de- 
bugging vehicle-use code, it is difficult to ascertain 
whether the problem originated from erroneous coding so 
or an improper original specification. Due to the difficulty 
in coding and debugging operation, the number of proc- 
ess steps necessary to ensure control program reliabil- 
ity is increased, which in turn prolongs the development 
period and increases development costs. 55 
[0007] The present invention was conceived in light 
of the above, and aims to provide a method and appa- 
ratus for assisting vehicle-use program development to 



develop highly reliable programs in a shorter period. 

DISCLOSURE OF INVENTION 

[0008] In order to achieve the above objects, accord- 
ing to the present invention, there is provided a method 
for assisting vehicle program development. In this meth- 
od, a vehicle control program is generated using a pro- 
gram generator having a function of generating a vehi- 
cle-use code from a control specification input. The gen- 
erated vehicle control program is downloaded to a ve- 
hicle ECU, which in turn executes the vehicle control 
program for debugging the vehicle control program. 
[0009] As described above, according to the present 
invention, a vehicle-use code is generated directly from 
a control specification, and downloaded to a. vehicle 
ECU. Because the original control specification is in 
common with the vehicle-use code, bugs are less likely 
to occur. Therefore, efficient debug operation can be 
achieved for smaller labor. Moreover, in the person 
hours required for coding operation can be significantly 
reduced.. 

[001 0] Debug operation at the debug step is prefera- 
bly performed in a program generator which inspects a 
result of execution of the vehicle control program by the 
vehicle ECU. Use of a program generator having acon- 
trol specification can facilitate a debut operation: 
[0011] According to another aspect of the present in- 
vention, there is provided an apparatus for assisting ve- 
hicle program development, comprising a chart gener- 
ation function of generating a data flowchart and a state 
flowchart indicative of a vehicle control specification, 
and a program code generation function of generating, 
based on the generated charts, a vehicle-use code for 
a vehicle control program having an integer logic to be 
processed by a vehicle ECU. Use of integer logic in the 
vehicle ECU is preferred because of the limitation of a 
memory size and an execution speed. In this embodi- 
ment, automatic /generation of vehicle-use codes are 
achieved through generation of integer logic codes 
based on data and state flowcharts. 
[0012] According to yet another aspect of the present 
invention, a simulation function is provided for simulat- 
ing the data flowchart with application of a floating point 
numbers corresponding to a physical value, and of an 
integer obtained by converting a floating point number, 
to output the simulation results. While conventionally a 
floating point number is handled at a simulation stage, 
while an integer is handled at a coding stage, according 
to the present invention, a floating point number and an 
integer are both handled at a simulation stage, and re- 
sults of processing with the both are output. With this 
arrangement, acceptability of integer logic can be easily 
judged at the specification generation stage. Preferably, 
a result of back calculation to obtain a floating point 
number from a result of simulation with an integer ap- 
plied thereto may be displayed so that a difference be- 
tween results of simulations with afloating point number 
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ic for a vehicle ECU; 

Fig. 5 is a diagram showing an example of a part of 
integer logic; 

Fig. 6 is a diagram showing structure of an integer 

s block; 

Fig. 7 is a diagram showing an example of an inte- 
ger block applied to multiplication; 
Fig. 8 is a diagram describing multiplication block 
processing of Fig. 7; 

10 Fig. 9 is a diagram showing a modified example of 
the process of Fig. 8; 

Fig. 10 is a diagram showing a support tool for In- 
teger logic; 

Fig. 11 is a diagram showing a support tool for inte- 
rs ger logic; 

Fig. 12 is a diagram showing a support tool for in- 
teger logic; 

Fig. 13 is a diagram showing a support tool for in-, 
teger logic; 

20 Fig. 14 is a diagram showing a support tool for in- 
teger logic; 

Fig. 15 is a diagram showing a support tool for in- 
teger logic; 

Fig. .16 is a diagram showing a support tool for in- 
25 . teger JogiQ; • • ;; y*.-.:-«v ; : ,• -*»v— ■.; 

Fig. 17 is a diagram describing a method for deter : 

minirigian operation: order; 

Fig. 18 is adiagram showing a priority function for 

defining an operation order in the embodiment; ' 
30 Fig. 1 9 is a diagram showing C code resulting from 

the process of Figs. 17 and 18; 

Fig. 20 is a diagram showing example G code gen- . 

erated based on a data flowchart; - 

Fig. 21 is a diagram showing a C code generated 
35 based on the same data flowchart as that in Fig. 20, 

and given Jabeling in the embodiment; 

Fig. 22is a diagram showing grouping process in C 

code generation ;• ■ .\- W;. :...;/.- : 

Fig. 23 is a diagram showing variable namedata 
40 base and expression database which are generated 

in C code generation; . 

Fig. 24 is a diagram showing grouping process uti- 
lizing the database of Fig. 23; 
Fig. 25 is a diagram showing an example of group- 
45 ing process; and 

Fig. 26 is a diagram showing an example of a dis- 
play screen when the program generator monitors 
engine control. 



applied thereto and of an integer applied thereto, re- 
spectively can be determined. 

[0013] Further, a block symbol in the data flowchart 
has information on a floating point number, an integer, 
an integer conversion condition from a floating point 
number to an integer, and a result of back calculation to 
obtain an integer from a floating point number using the 
integer conversion condition. Vehicle-use codes are au- 
tomatically generated utilizing integer information of the 
block symbol. 

[0014] According to still another aspect of the present 
invention, a priority function is provided for defining an 
order to execute a plurality of data flowcharts in the 
same hierarchy in the state flowchart. With this function, 
an efficient and appropriate control program can be re- 
liably generated. 

[0015] According to still another aspect of the present 
invention, a labeling function is provided to assign a de- 
sired label to a selected symbol connection line in a data 
flowchart, and a vehicle-use code is generated in which 
the label is used as a variable name for the part to which 
the label is attached: When the attached label which is 
easily understandable for a user, a readable vehicle-use 
code can be generated. . 

[001 6] According to yet another aspect of the present 
invention, a grouping function is provided for grouping, 
in vehicle-use code generation, a plurality of processes 
corresponding to a plurality of block symbols in the data 
flowchart. Preferably, grouping is carried out according 
to a predetermined grouping restriction condition which 
defines the number of block symbols to be grouped. Fur- 
ther preferably, a part with a label attached thereto, of a 
symbol connection line is set as a grouping break. With 
grouping, readability of a vehicle-use code can be im- 
proved. 

[0017] Vehicle-use code of the present invention can 
be. readily embodied as G language code having been . 
modified so as to suit to.a.vehicle ECU, but is not limited 
to C code. A vehicle ECU of the present invention is a 
desirable ECU to be mounted to a vehicle, such as an 
engine ECU, a transmission ECU, a suspension control 
ECU, and a break control ECU. It is needless to say that 
control specification and vehicle specification which are 
. necessary in program development may be different de- 
pending on an ECU and vehicle-mounted devices to be 
controlled. 

BRIEF DESCRIPTION OF DRAWINGS 
[0018] 

Fig. 1 is a diagram showing a complete structure of 
a preferred embodiment of the present invention; 
Fig. 2 is a block diagram showing a structure of a 
program generator; 

Fig. 3 is a data flowchart and a state flowchart in- 
dicative of control specification; 
Fig. 4 is a diagram illustrating concept of integer log- 



so BEST MODE FOR CARRYING OUT THE INVENTION 

[001 9] In the following, a preferred embodiment of the 
present invention will be described with reference to the 
accompanying drawings. 
55 [0020] Referring to Fig. 1 , a program generator 1 has 
functions of generating and simulating a control speci- 
fication, and for generating vehicle-use C code from the 
generated control specification. 
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[0021] The program generator 1 comprises a compu- 
ter, having, as shown in Fig. 2, a CPU 10, a ROM 11, a 
RAM 12, a keyboard 13, a pointing device 14, a display 
15, a hard disk 16, a communication circuit 17, and a 
CD-ROM drive 18. A program for achieving the respec- 
tive functions of the program generator 1 is stored in 
either the ROM 1 1 , the hard disk 1 6, or the CD-ROM 1 9, 
and executed by the CPU 1 0. An input/output device is 
not limited to a keyboard 13, a pointing device 14, and 
a display 15. Any type of memory device other than a 
CD-ROM 19, such as DVD, may be used. Any type of 
memory device other than a hard disk 16 may be used. 
[0022] The user writes a specification incorporating 
his idea on the display 15 by operating the keyboard 13 
and the pointing device 14 (a mouse and so on), and 
thereupon the control specification is; shown on the dis- 
play 1 5 in the form of a data flowchart (a block diagram) 
and a state flowchart (a state transition chart, a state 
transition diagram), as shown in Figs. 3(a), 3(b), a data 
flowchart showing a partial data flow, a state flowchart 
showing an entire control flow. 

[0023] The user also inputs a vehicle specification by 
operating the keyboard 13 and the pointing device 14 
so that a hypothetical vehicle model is formed in the pro- 
gram generator 1 ; Specifically, a vehicle model is 
formed as a collection of expressions which describe 
various vehicle motions and operations, and so on; ' • 
[0024] In response to the user's instructions, the gen- 
erated specification (data and state flowcharts) is simu- 
lated. Specifically, as shown in Fig. 1 , the vehicle model 
is controlled on the computer according to the control 
specification logic. When a simulation result is shown 
on the display 15. necessary debugging is applied. In a 
debug operation, the specification is modified and im- 
proved for completion. 

[0025] When the specification completes, vehicle-use 
C code Is generated based on the complete specifica- 
tion In response to the user's instruction. Specifically, a 
file "containing code written in the C language and cor- 
responding to the data and state flowcharts is formed. 
A vehicle-use C code has an'integer logic and a struc- 
ture enabling higher speed processing using a smaller 
memory in size, compared to general C code (described 
below). A resultant vehicle-use C code is downloaded 
to an actual vehicle ECU 2, e.g., an engine ECU. 
[0026] The vehicle model is input from the program 
generator 1 to the vehicle model device 3. The vehicle 
model device 3, including a DSP, simulates high speed 
interruption and other characteristics of the vehicle ECU 
2. Conducting such a simulation before testing using an 
actual vehicle reduces development period and results 
in a more effective product. After the vehicle model de- 
vice 3 is connected to the vehicle ECU 2, the vehicle- 
use C code, having been loaded into the ECU 2, is ex- 
ecuted to begin simulation in a near-real environment. 
Operation of the vehicle ECU 2 and vehicle model de- 
vice 3 are monitored by the program generator 1 via the 
communication circuit 17, and a debug operation is ap- 



plied in the program generator 1. For example, should 
improper control operation be found, the cause thereof 
is detected using the data and state flowcharts. Then, 
improper points are amended in the computer, and the 

5 amended logic is verified. 

[0027] After debugging is completed, the vehicle ECU 
2 is mounted to a vehicle 4 for actual testing. In actual 
testing, any defect in need of amendment due to a non- 
linearity factor and so on of an actual vehicle is detected 

10 for final program amendment. 

[0028] In the following, a program generator 1 will be 
described in more detail. 

Control Specification Input/Generation Function 
15 (Integer Logic) 

[0029] Conventionally, at a control specification input 
stage, a chart is prepared for processing a floating point 
number indicative intact of a physical value. Next, a sim- 

20 ulation is carried out using the floating point number, so 
that acceptability of the control specification can be de- 
termined based on the simulation result. Therefore, C 
code which is automatically generatedfrom the chart us- 
ing a conventional function contains a floating point 

25 number. v-iy- ->.■*• ■■-.-;■;»;.":." :■ t- 

[0030] Here;.vehiclecontrol requires making best use 
of the capacity of -the CPU. of an ECU in view of mink - 
mizing cpstsand increasing processing speed. This de- ... 
mand is particularly significant in control of devices with • 

30 high speed rotation, such as an engine. In order to meet 
such a demandi preferably, integer logic (a fixed point 
number) is applied to C code for a vehicle-use ECU to 
generate C code with a data. bit of a different number 
from that of general C code. This is a significant differ- 

35 ence between, vehicle- use G code and automatically 
generated general G code, and a major reason for forc- 
ing manual generation of vehicle-use C code. . 
[0031] In this embodiment, an integer bJock (de- : 
scribed later) is introduced so that integer logic can be ■■ 

40 taken into consideration as early as at a control specifi- 
cation input stage, and whereby vehicle-use C codes 
having an integer logic can be automatically generated .. 
from a control specification. . 

^5 (1) Conversion, from Floating Point Number to Integer 

[0032] A floating point number is converted into an in- 
teger, following the below expression (1). 



50 



x_int=int(x_float-OFFSET)/SLOPE 



d) 



wherein x_f!oat is a floating point number, x_int is an 
integer, OFFSET (or bias) and SLOPE (or LSB) are in- 
55 teger conversion condition. 
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(2) Summary of Integer Logic 

[0033] Fig. 4 illustrates the concept of integer logic in 
a vehicle ECU. The sensor 21 sends a voltage signal v 
according to a detected physical quantity p to an A/D 5 
converter 22. The A/D converter 22 converts the re- 
ceived voltage signal v into integer data P to send to the 
vehicle ECU 2. Using integer logic, the vehicle ECU 2 
obtains integer data Q for a control parameter from the 
integer data P of a detection signal. Integer data may 
be, e.g., an unsigned integer of 16 bits. The integer data 
Q is converted into a control signal to be output to an 
actuator 23, or an object to be controlled, for generation 
of physical quantity q. 

[0034] I n Fig. 4, the integer logic must produce a result 
equivalent to that which would be produced according 
to the original control logic with respect to a physical val- 
ue. SLOPE, OFFSET at the input/output portion of the 
vehicle ECU 2 are Ip, Iq, op, oq, respectively. In actuality, 
integer logic includes a plurality of operation process 
stages, and has many SLOPEs, OFFSETS in an inter- 
mediate process. These SLOPEs, OPPSETs should be 
set such that the integer logic is optimized in view of a 
memory size and an execution time. 
[0035] In a case wherein a control specification (logic) 
generated by a user includes a transfer function, as 
shown in Fig. 5, and identical SLOPE is used for all sev- 
en items of the transfer function in constituting an integer 
logic, the seventh item may be always caused zero 
when SLOPE which is suitable for the first item is applied 
to all seven items because factors differ significantly be- 
tween the first and seventh items. 
[0036] Generally, too small a SLOPE may cause over- 
flow, while too large a SLOPE may result in negligence 
of an input of a sensor. Further, setting an improper 
SLOPE may result in a control logic containing a lengthy 
component. In order to avoid these problems, readily 
setting of a suitable integer conversion condition is de- 
sired. 

(3) Integer Block 

[0037] In order to generate a suitable integer logic in 
a data flowchart so that suitable integer conversion con- 
dition can be readily set, an integer block, shown in Fig. 
6, is introduced in this embodiment. An integer block is 
a block symbol used in a data flowchart, which a user 
can write into a data flowchart. 

[0038] As shown in Fig. 6, an integer block includes 
six types of information pieces, namely (1) integer, (2) so 
SLOPE (LSB), (3) OFFSET (bias), (4) float (a floating 
point value), (5) Data Type, (6) "integer* SLOPE + 
OFFSET' . (6) is a back float, or a result of back calcu- 
lation to obtain a float from an integer. 
[0039] Function of an integer block will be described ss 
referring to Figs. 7 and 8 and using multiplication as an 
example. 

[0040] In the data flowchart of Fig. 7, input data 1 , 2, 



and SLOPE and OFFSET for each data are input to a 
multiplication block. The multiplication block obtains the 
above mentioned six types of data items from these in- 
puts, and outputs them. 

[0041] Fig. 8 shows an expression describing a proc- 
ess in a multiplication block. In this process, input values 
x, y are converted into integers using offsets 1, 2, and 
slopes 1 , 2, respectively, and a product of the two inte- 
gers is output (integer output). Meanwhile, a float output 
is "xy". Comparison between expression (1) and M xy" 
leads to SLOPE and OFFSET on the output side (Fig. 
8, expressions (2), (3)). Further, a back float (=integer * 
SLOPE OUT + OFFSETqut) is a,so output. 
[0042] The user can ascertain the simulation result by 
referring to the display in Fig. 7. "Float" indicates wheth- 
er or not basic control logic is correct. Further, "float" 
and "back float" are compared. When the difference 
(0.1) is within a tolerable range, it is known that integer 
logic is appropriate: On the other hand, when the differ- 
ence is not within the tolerable range, it is known that 
inappropriate integer logic, or integer conversion condi- 
tion, namely "slopes 1, 2", is set; Then, "slopes 1, 2" are 
repeatedly adjusted until an appropriate result is ob- 
tained. ; : " 1 ■ '■ . :i - 

[0043] ; Figs. 7 and 8 show only a part of a control specr 
ification.Jn actuality, control specification constitutes of 
a series of numerous connected blocks. In this embod- 
iment, "SLOPE": can be verified and:adjusted in each 
block in a control process; For example, when a signif- 
icant difference is found between "float" and "integer" in 
a certain block, integer conversion condition is adjusted 
in any block preceding the focused: block. 
[0044] With the above. arrangement, "float 1 - and "inte- 
ger" can have substantially equivalent meaning over the 
entire control process. In other words, a situation with a 
difference between "float" and "integer" becoming larger 
as it goes to latter blocks* can be^voided.rAlso, a situ- 
ation in which input of a certain; sensor is ignored be- 
cause of an improper SLOPE set, can be avoided. 
[0045] As shown in the third express ion in Fig. 8, OFF- 
SET on an output side includes input values x, y. When 
the influence thereof is not negligible, the user can 
chose modified process, as shown in Fig. 9, Specifically, 
"offset/slope" is added to an integer prior to the multipli- 
cation whereby the item for "offset" on the output side 
becomes zero, as. is shown in the first expression in Fig. 
9. 

[0046] Note that, although multiplication is used as an 
example in the above to describe a function of an integer 
block, similar function can be set to other operations. 
Figs. 10to 16showvariousintegerblockswhich support 
integer logic. Although information y(5) to y (8) are added 
to anintegerblockinthistool.asshownin Fig. 10, basic 
information y(1) to y(4) is the same as described above. 
Also, LSB in Figs. 10 to 1 6 corresponds to "slope". 
[0047] As described above, in this embodiment, as a 
result of introduction of an integer block, a control spec- 
ification in the form of a chart expresses an integer logic. 
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As suitable integer conversion condition can be set 
through comparison between theoretical control logic 
(real number operation) and integer logic (integer oper- 
ation), suitable integer logic including fewer bugs can 
be easily made. The complete control specification itself s 
is usable for a computer simulation. In addition, vehicle- 
use C code can be automatically generated by extract- 
ing an integer logic part from the specification. As the 
control specification and vehicle-use C code have parts 
in common, bug generation is reduced at a code gener- 10 
ation stage, and program verification, such as debug- 
ging, can be easily applied. 



Priority Function (Regulation of Operation Order) 
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[0048] For determination of an order to execute a plu- 
rality of modules or operational expressions, generally, 
each module or operation expression is made into a trig- 
gered subsystem and given a function call from a state 
flowchart, as shown in Fig. 17. 20 
[0049] In this embodiment, a priority function is addi- 
tionally provided, as shown in Fig.18. Specifically, the 
user imparts a number indicative of a priority order to 
the data flowchart, whereby each module or operation 
expression is made as a prioritized subsystem 25 
(1_Prior_Subsystem, 2_Prior_Subsystem). Operations 
are executed in the order of names of the subsystems. 
[0050] The priority function leads to an advantage that 
an order to execute operations in data flowcharts in the 
same hierarchy can be easily determined. In addition, 30 
another advantage can be achieved that a C cod which 
is easier than conventional one can be generated. This 
is preferable in view of readability and a memory capac- 
ity. 



C Code Generation (Labeling) 
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[0051] C code generation is applied in response to a 
user's instruction. As described above, as a result of ap- 
plication of an integer block, each block in a data flow- 40 
chart has integer information. Therefore, a series of 
block groups can be processed using integer opera- 
tions. By generating integer operations, vehicle-use C 
code having an integer logic are generated. Specifically, 
referring to the example in Fig. 7, integer operations (two 45 
integer inputs and one integer output) are extracted, at 
a chart level, from information groups to be input or out- 
put with respect to a multiplication block. 
[0052] In order to modify an extent software product 
for the above use, a tool for automatically producing a 50 
general C code based on a chart and a modeling tool 
into which a C code is written are prepared, and the 
model is modified so as to suit to the integer logic. Then, 
processing which is absent from a general C code and 
unique to a dedicated command, and a dedicated com- 55 
mand resulting from a modified general C code are also 
applied. 

[0053] Fig. 20 shows an example of a C code gener- 



ated from a data flowchart. According to a general C 
code generation method, computer-determined varia- 
ble names are given to the respective parts, as shown 
in the drawing. This results in a difficult to read C code 
unfriendly to human users. 

[0054] That is, readability is not fully taken into con- 
sideration in a general C code automatic generation 
method, which is mainly concerned with coincidence be- 
tween a C code and a chart. Nevertheless, often a pro- 
gram developer must read a C code in testing using an 
actual ECU, which is conducted for motion verification 
in vehicle system development. Therefore, user friend- 
liness is desired in automatic vehicle-use C code gen- 
eration. 

[0055] In this embodiment, a labeling function, as 
shown in Fig. 21, is employed to improve readability. A 
user clicks a connection line in a block symbol in the 
data flowchart, in response to which a desired label is 
attached to the selected connection line. In Fig. 21 , as 
an example, labels "t_x", n t _y", "t_z°, "t_xyz" are at- 
tached. In actuality, more easily understandable labels, 
such as a module name, a sensor name, and so on, are 
preferably attached. In C code generation, the label may 
be usedas a variable name -of the part with that label 
attached. As a.result, easiJy readable C codes are gen- < ; 
erated, as shown in Fig. 21. ; 

[0056] Note that labels may be attached to only a de- 
sired line, rather than to all connection lines, as shown . 
in Fig. 21, as the former may help -easy reading of C 
codes. As for a line without labeling,: a computer-deter- 
mined variable names may be used intact. 

Grouping in C Code Generation .: 

[0057] 

(1) In general C code generation, a different varia- 
ble name is given to each block in a data flowchart, 
and an expression for introducing one variable is. : 
generated corresponding to each block. Therefore, 
resulting C code contains numerous variables and . : 
expressions, making it long and less readable. 

In order to address this problem, in this embod- 
iment, a grouping function is employed to improve 
readability. In Fig. 22, there are two blocks interven- 
ing between input and output. With C code on the 
leftside without grouping, two expressions are gen- 
erated according to the number of blocks. With C 
code on the right side with grouping, operations for 
two blocks are integrated into a single expression, 
in which variable names unnecessary for a user 
reading a C code are deleted, and easily readable 
C code is thereby generated. 

Here, grouping of too large a number of blocks 
may result in a lengthy expression with poor read- 
ability. To address this problem, a condition for de- 
fining the number of blocks contained in one group 
is preferably determined. In this example, the max- 
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imum number of such blocks is set at two. That is, 
for one expression of a C code, operations will be 
carried out twice at maximum. 

Grouping process will next be described with 
reference to Figs. 23 and 24. In C code generation, 5 
ID is attached to each block in a data flowchart for 
use as a variable name. Then, a variable name (sig- 
nal name) database is made for correlating ID and 
a user-designated label (Fig. 23 (a)). When no cor- 
responding label can be found, ID is used intact. 10 

In Fig. 24, ID of an input signal to a focused 
block is detected, using a function to detect an input 
signal (S11). Then, whether or not grouping condi- 
tion (twice at maximum) is held with each input sig- 
nal is determined with reference to an expression is 
database (Fig. 23 (b)) (S12) and when the result is 
negative (less than twice), the expression database 
is searched (S13) to adopt an expression corre- 
sponding to an input ID. On the other hand, when it 
is determined that the condition is held, a variable 20 
name database is then searched (S14) to employ a 
corresponding label as a variable name. When no 
attached label is detected, an ID is used. 

Using an expression employed at S1 3 or a var- 
iable name employed at S14, an expression for the 25 
focused block is generated (S1 5), Whether or not a 
grouping condition is held with respect to the gen- 
erated expression is detected (S1 6). When it is not. 
the expression generated at S1 5 is registered to the 
expression database forpreparation forthe process 30 
in the next block (S17). On the other hand, when 
the condition is held, the expression generated at 
S1 5 is written into a file (S1 8). In Fig. 22, an expres- 
sion for two blocks combined is output. 

With reference to Fig. 25, a specific example of 35 
the above grouping processing will be described 

With input signals S1 , S2, an expression data- 
base is searched with respect to an input signal S1 
to obtain an expression (x+1). As the number of 
grouping for this expression is only once (i.e., the *o 
above mentioned condition is held), the expression 
(x+1) is used as an input signal. Then, a search is 
carried out with respect to an input signal S2. As the 
number of grouping for an input signal S2 is twice, 
a variable name database is then searched to adopt 
label x2 as an input signal. Therefore, an operation 
within the focused block will be ,, (x-f1)*x2" (multipli- 
cation). 

Next, an output signal t_x is retrieved from the 
variable name database. As two groupings have so 
been conducted with respect to the input signal S1 , 
the grouping condition is held. Then, t_x=(x+1)*x2 
is output. If grouping condition is still to be held at 
this stage, the generated expression is registered 
in the database. 55 

(2) In grouping processing, a part in a chart, where 
a label is attached is always determined as a group- 



ing break. All labels attached by the user are con- 
tained in an operation expression for a C code. 
When labels attached to an appropriate part are as- 
signed from a chart prepared by a human user, C 
code having a structure corresponding to that of the 
chart is generated. With this processing, more eas- 
ily readable C code is automatically generated. 

[0058] in an example wherein a user attaches a label 
to the beginning and end of a data flowchart, very read- 
able C code is automatically generated, which has def- 
inite variables at the beginning and end thereof and 
process segments in appropriate intervals. 
[0059] As described above, according to this embod- 
iment, when grouping is applied in C code generation, 
readability of an automatically generated C code can be 
improved, and memory can be conserved through re- 
duction of variable names. • 

Download to Vehicle ECU 

[0060] As described above with reference to Fig. 1, 
the program generator 1 downloads an automatically 
generated vehicle-use G codes to the vehicle ECU 2 in 
response to a user's instruction. The vehicle ECU 2 then 
executes the downloaded vehicle-use.C code to control 
the vehicle model device 3 (DSP). The program gener- 
ator 1, monitoring : the control being executed, displays 
the execution state in an appropriate format on the dis- 
play. Fig. 26 shows an example of a monitor screen . 
when the vehicle ECU 2 is an engine ECU. The user 
operates the program generator to conduct motion ver- 
ification and a debug operation with respect to' a vehicle- . 
use C code. 

[0061] In this embodiment,, a suitable vehicle-use G 
code having few bugs is generated. The vehiclerUse C 
code is in common with the original control^ logic. The 
vehicle-use C code has higher readability. Therefore, a 
debug operation can be easily and efficiently performed. : 
[0062] As described above, according to the present 
invention, as a vehicle-use code corresponding to the 
control specification input by the user is automatically 
generated, the number of coding operation steps can 
be significantly reduced. The input control specification 
itself is usable for computer simulation , as well as usable 
in a vehicle-ECU after conversion into a vehicle-use. 
code. This enables significant reduction of the number 
of debug operation steps . As a result, the number of 
steps necessary to ensure reliability can be reduced, as 
well as a development period and costs. The advantage 
of the present invention for assisting a process from 
preparation of a specification to logic debugging, is re- 
markable particularly in a situation with overgrown and 
complicated vehicle control programs. 
[0063] Also, according to the present invention, a 
highly readable vehicle-use code can be automatically 
generated. As a result, the number of steps for a debug 
operation and so on can be further reduced. 
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INDUSTRIAL APPLICABILITY 

[0064] As described above, a method and apparatus 
for assisting development of a vehicle-use program ac- 
cording to the present invention can be utilized in devel- 
opment of a vehicle control program to be executed by 
a vehicle ECU. 



Claims 

1. A method for assisting development of a program 
for a vehicle, comprising: 

a program generation step of generating a ve- 
hicle control program using a program genera- 
tor having a function for generating a segment 
of vehicle-use code based on a control specifi- 
cation input; 

a downloading step of downloading the gener- 20 
ated vehicle control program to a vehicle ECU; 
and 

a debug step of debugging the vehicle control 
program by causing the vehicle ECU to execute 
the vehicle control program. 25 



2. 



4. 



10 



15 



A method for assisting development of a program 
for a vehicle according to claim 1 . wherein 

debugging at the debug step Is carried out in 
the program generator which inspects a result of ex- 30 
ecution of the vehicle control program by the vehicle 
ECU. 

A method for assisting development of a program 
for a vehicle according to claim 2, further compris- 35 
ing: 

a control execution step of connecting the ve- 
hicle ECU to a vehicle :model device which 
models a vehicle to be controlled, to cause the 40 
vehicle ECU to control the vehicle model de- 
vice; and 

an inspecting step of inspecting the vehicle 
ECU and the vehicle model device while control 
is applied. 45 

A method for assisting development of a program 
for a vehicle according to claim 3, further compris- 
ing: 



8. 



for a vehicle according to any one of claims 1 to 4, 
wherein the segment of vehicle-use code is a seg- 
ment of general code modified to suit an integer log- 
ic to be processed in the vehicle ECU. 

. A method for assisting development of a program 
for a vehicle according to claim 5, wherein a vehicle 
control program is generated at the program gen- 
eration step, so as to accord to an integer conver- 
sion condition input into the program generator. 

A device for assisting development of a program for 
a vehicle, comprising: 

input means for inputting a vehicle control spec- 
ification; 

program generation means for generating a 
segment of vehicle-use code for a vehicle con- 
trol program based on the control specification; 
download means for downloading the vehicle 
control program to an external vehicle ECU; 
and 

output means for outputtihg a result of execu- 
tion of the vehicle control prograrrvby the vehir 
cle ECU. . - • f-rc 

A device for assisting development of a program for 
a vehicle f :comprising: ..- 

a chart generation function for generating a da- 
ta flowchart and a state flowchart indicative of 
a vehicle control specification; and 
a program code generation function for gener- 
ating, based on the charts generated, a seg- 
ment of vehicle-use code for a vehicle control 
program having an integer logic to be proc- 
essed by a vehicle ECU. 

A device for assisting development of a program for 
a vehicle according to claim 8, . further comprising: 
a simulation function for simulating the data 
flowchart with application of a floating point number 
corresponding to a physical value and of an integer 
obtained by converting a floating point number, to 
output results of simulations with floating point 
number applied thereto and of the integer applied 
thereto, respectively. 



so 

a model generation step of generating a vehicle 
model in the program generator based on a ve- 
hicle specification input; and 
a model download step of downloading the ve- 
hicle model generated at the model generation 55 
step to the vehicle model device. 



10. A device for assisting development of a program for 
a vehicle according to claim 9, wherein a result of 
back calculation to obtain a floating point number 
from a result of simulation with an integer applied 
thereto is displayed so that a difference between re- 
sults of simulations with the floating point number 
applied thereto and of the integer applied thereto, 
respectively, can be determined. 



5. A method for assisting development of a program 11. A device for assisting development of a program for 
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a vehicle according to claim 10, wherein the data 
flowchart has a block symbol which includes infor- 
mation concerning a floating point number, an inte- 
ger, an integer conversion condition from a floating 
point number to an integer, and a result of back cal- 
culation to obtain an integer from a floating point 
number using the integer conversion condition. 

1 2. A device for assisting development of a program for 
a vehicle according to claim 11 , wherein the integer 
conversion condition is able to be adjusted based 
on a result of the simulation. 

1 3. A device for assisting development of a program for 
a vehicle according to any one of claims 8 to 12, 
further comprising 

a priority function for defining an order for ex- 
ecuting a plurality of data flowcharts in a same hi- 
erarchy in the sate flowchart. 

1 4. A device for assisting development of a program for 
a vehicle according to any one of claims 8 to 13, 
further comprising 

a labeling function for assigning a desired label 
to a symbol connection line desirably selected 
. in the data flowchart, 
wherein 

a vehicle-use code using the label as a variable 
name of a part with the label attached is gen- 
erated. 

.15. A device for assisting development of a program for 
a vehicle according to. any one of claims 8 to 14, 
further comprising . . .. 

a grouping function for grouping a plurality of 
• processes corresponding to a plurality of block sym- . 

bols in the data flowchart when the vehicle-use 
. code is generated. • \ 

16. A device for assisting development of a program for 
a vehicle according to claim 15, wherein grouping 

. . is applied according to a predetermined grouping 
restriction condition which defines a number of 
block symbols to be grouped. 

17. A device for assisting development of a program for 
a vehicle according to claim 15 or 16, further com- 
prising 

a labeling function for assigning a desired label 
to a symbol connection line desirably selected 
in the data flowchart, 
wherein 

a part with the label attached thereto is set as 
a grouping segment. 



16 

a vehicle according to any one of claims 8 to 17, 
wherein a segment of vehicle-use C code is gener- 
ated by modifying, using the program code gener- 
ation function, a segment of general C code to suit 
5 a vehicle ECU. 

1 9. A computer readable memory medium for use in as- 
sisting development of a program for a vehicle, 
bearing a program causing a computer to execute 

10 

a chart generation function for generating a da- 
ta flowchart and a state flowchart indicative of 
a vehicle control specification, and 
a program code generation function for gener- 
is ating, based on the generated chart, a segment 
of vehicle-use code for a vehicle control pro- 
gram having an integer logic to be processed, 
by a vehicle ECU; 

20 
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Fig. 2 
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y(k) =-0.788.8 y(k-l) + 
0.1784 y(k-2) - 
0.1000 y(k-3)- 
0.0010 u(k) + 
0.0150 u(k-l) - 
0.0040 u(k-2) - 
0.0020 u(k-3) 



EXAMPLE OF AN EXPRESSION INCLUDING 
A FLOATING POINT NUMBER 
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Fig. 10 
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Fig. 11 
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Fig. 13 
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Fig. 14 
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Fig. 15 
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Fig. 16 
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Fig. 17 
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Fig. 20 



INTEGER CONSTANT 
INTEGER CONSTANT 1 



:0-D> 



DISPLAY 



void untitled(void) 
{ 

s 1 6 s 1 _SJFunction; 
sl6 s2_S_Function; 
s 1 6 s4_S_Functi on; 
sl6 s3_S_Function; 

/* int_sum : s4_S_Function */ . I 
s4_S_Function = sl_S_Function+s2_S_Function; 



'* int_gain : s3_S_Function */ 
s3_S_Function = (sl6)(2*s4_S_Function); 



/ 

s3 



/* (no update to perform in root model) */ 



} 
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Fig. 21 



t x 



INTEGER CONSTANT 



t z 



int_sum intjain 







t xyz 





t_y 

INTEGER CONSTANT 1 



DISPLAY 



void untitled(void) 
{ 

si 6 t_x; 
sl6t_y; 
sl6t_z; 
sl6t_xyz; 

/* int_sum : s4_S_Fimction */ 
t_z = t_x+t_y; 

/* int__gain : s3_S_Function */ 
t_xyz = (sl6)(2*t_z); 



/* (no update to perform in root model) */ 



} 
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Fig. 22 
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Fig. 23 



GROUPING 



ID 



Signal Label 



(a) 



si S Function t x 



ID 



EXPRESSION 



(b) 



sl_S_Function xl *x2 
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Fig. 24 
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Fig. 25 
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